1. Field of the Invention
The invention relates to application programming interfaces (APIs). More particularly, the invention relates to language independent API implementations and methods.
2. Description of the Related Art
Within a computer system, an application (or application software) typically is software meant to perform a specific task for the computer user. Also, within a computer system, a programming library includes a collection of functions that are useful in the development and execution of the application software. Conventionally, programming libraries provide access to their functions via an Application Program Interface (API), and through API calls or functions calls that accept various input parameters in the correct syntax for the language in which the API is written. However, such approach to accessing library functions does not allow relatively easy cross-language usage, e.g., an application written in a first programming language and a library written in a second programming language. In such cases, different interpreters and possibly other computer system components must be used to convert one language's data structures to another language's data structures. Such process can be relatively error prone and time consuming. Also, depending on the complexity of the library, the number of functions for the API could be relatively large, which increases the difficulty of building the interpreters.
Conventional programming libraries are written to targeted languages and in a manner that performs the needed functions for the particular application. However, when another language needs to attach to the particular programming library, the new or other language uses existing tools provided with the language or uses external tools to wrap around the library. SWIG (Simplified Wrapper and Interface Generator) and JNI (Java Native Interface) are examples of inter-language communication software development tools that connect programs written in a (first) lower level programming language to a (second) higher level programming language. However, beyond providing access to the functions and data in the other language, such inter-language communication tools do not offer much in terms of providing relatively easy cross-language usage.
Conventional solutions for the difficulties of cross-language usage typically only ease the process of creating an inter-language communication tool, which still is troublesome. Depending on the size of the API, the task of communicating across different programming languages could be from a few functions and data classes to a few hundred or more functions and data classes. As the size of the API grows, so does the time required to build the interface between the application and the library, as well as the overall complexity of the interface. Also, different versions of data structures or functions may exist, which compounds the existing difficulties. Using conventional methods, an inter-language interface becomes essentially a rewrite of the external API to properly convert all data types and functions to a usable version in the programming language of the application.
Conventional approaches can be further complicated when modifications are made to the API. When a modification to the API occurs, programming developers must also change the interface and the application to accommodate the API modification. Furthermore, given the relatively complex nature of many conventional interfaces, API modification can result in the introduction of inadvertent bugs into the interface layer by programming developers. Depending on the scope of the modification, the amount of work could be reduced by a relatively significant amount if the interface used a language independent communication scheme.